Method for viewing document information on a mobile communication device

ABSTRACT

A process for viewing document information on a mobile communication device without having to retrieve the full document onto the device. The solution is client—server based. The client is the mobile device attachment viewing application and the server is the document (attachment) handling process on a remote machine. The process comprises server document information construction and delivery, and document information display on the mobile device.

FIELD OF THE INVENTION

The following is directed in general to displaying content on mobilecommunication devices, and more particularly to a method for viewingdocument information about a document, on a mobile communication device,without having to retrieve the full document onto the device.

BACKGROUND OF THE INVENTION

Mobile communication devices are becoming increasingly popular forbusiness and personal use due to a relatively recent increase in numberof services and features that the devices and mobile infrastructuressupport. Handheld mobile communication devices, sometimes referred to asmobile stations, are essentially portable computers having wirelesscapability, and come in various forms. These include Personal DigitalAssistants (PDAs), cellular phones and smart phones. While their reducedsize is an advantage to portability, bandwidth and processingconstraints of such devices present challenges to the downloading andviewing of documents, such as word processing documents, tables andimages. Also, as a result of their enhanced levels of functionality andcomputing power, handheld mobile communication devices are increasinglysusceptible to attack by computer viruses.

Computer hackers commonly use email attachments as virus carriers toattack corporate network-connected computers. Therefore, emailattachments are often identified as presenting a security threat forcorporate networks. In order to protect such networks, many corporationsand organizations use sophisticated systems to safely handle emailattachments. One of the more common corporate approaches is to employdocument management systems. One feature of such systems is that theyusually rename email attachments with a common extension, for example“.tmp”.

When the user of a mobile device receives an email with renamedattachments it is difficult for the user to determine which attachmentis of interest based on file names alone. For example, if a mobiledevice user receives an email with attachments named 0001.tmp, 0002.tmpand 0003.tmp, and only one of them is a MS WORD® document that is ofinterest, the user is unable to identify the document from the commonfile extensions. The normal recourse in such a situation is to retrievethe document contents for all attachments from the remote documentserver, and successively review the documents in order to identify thedesired one.

However, the downloading of an entire document from the server to amobile communication device consumes a large amount of bandwidth,especially when the document is large. In addition, viewing even aportion of such a downloaded document on the device consumes substantialdevice CPU/memory/battery resources.

SUMMARY OF THE INVENTION

According to an aspect of the invention, a method is provided forviewing document information on a mobile communication device (e.g.type, creation time, etc), without having to retrieve the full documentonto the device. The solution is client—server based. The client is themobile device attachment viewing application and the server is thedocument (attachment) handling process on a remote machine. This methodincludes two operational steps: server document information constructionand delivery, and document information display on the mobile device.

By using the method set forth herein, a user is able to identify adocument of interest, without retrieving the document content from theserver for each attachment in an email. This minimizes bandwidth usageand provides an enhanced on-demand attachment viewing experience. Also,eliminating unnecessary document content transmission to the deviceminimizes device power consumption.

Additional aspects and advantages will be apparent to a person ofordinary skill in the art, residing in the details of construction andoperation as more fully hereinafter described and claimed, referencebeing had to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

A detailed description of the preferred embodiment is set forth indetail below, with reference to the following drawings, in which:

FIG. 1 is a block diagram of a network environment in which thepreferred embodiment may be practiced;

FIG. 2 is a tree diagram showing the basic structure of a DocumentObject Model (DOM) used in the preferred embodiment;

FIG. 3 shows the top-level of the DOM structure in FIG. 2;

FIG. 4 shows an exemplary DOM structure for a word processing document;

FIG. 5 shows an exemplary DOM structure for a table document:

FIG. 6 shows an exemplary DOM structure for a word processing documentcontaining an image subdocument;

FIG. 7 is a flowchart showing document information construction anddelivery according to the preferred embodiment; and

FIGS. 8A and 8B show static and dynamic display, respectively, ofdocument information on a mobile communication device according to thepreferred embodiment

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference to FIG. 1, network environment 10 is shown in which thepreferred embodiment may be practiced. Network environment 10 includesmobile devices 12 communicating via a wireless network 14 to a server 28for downloading document attachments to the mobile devices 12. Whileonly one server 28 is shown for illustration purposes, a person of skillin the art will understand that network environment 10 could have manysuch servers for hosting web sites or graphic download sites, providingaccess to picture files such as JPEG, TIFF, BMP, PNG, SGI, MP4, MOV,GIF, SVG, etc. As would be understood by one of ordinary skill in theart, wireless network 14 may be a GSW/GPRS, CDPD, TDMA, iDEN Mobitex,DataTAC network, or a future network such as EDGE or UMTS, or abroadband network such as Bluetooth and variants of 802.11.

A connection to a fixed service requires special considerations, and mayrequire special permission as authorized through a Network Access Point(NAP) 16. For generic services, such as web access, a proxy-gateway orNetwork Address Translator (NAT) 18 may be provided so that a networkoperator can control and bill for the access. NATs 18 enable managementof a limited supply of public Internet addresses for large populationsof wireless mobile devices. Solutions offered by a proxy-gateway or NAT18 often involve a complex infrastructure, and thus may be managed byvalue-added service providers (VASPs), which provide, for instance, WAPgateways, WAP proxy gateway solutions, multi-media messaging servers(MMS) and Internet Multi-Media Services (IMS).

Private Intranet services 26 may require an associated Private IntranetProxy Gateway 24 for accessing content on server 28. Such privateservices include WML access to corporate mail systems, HTML access toCRM databases, or any other services that deliver information asformatted data with links and URLs embedded. As shown, it is possiblethat a private service 26 may be connected directly to the wirelessnetwork 14, as opposed to being connected via Internet 20.

Referred to throughout this document, for the purpose of describing thepreferred embodiment, is the structure of a Document Object Model (DOM)for a document attachment to be viewed on a mobile device 12.

The attachment server 28 uses a file-parsing distiller in the preferredembodiment, for a specific document type, to build an in-memory DocumentObject Model (DOM) structure representing an attachment of that documenttype. The document DOM structure is stored in a memory cache of server28, and can be iterated bi-directionally.

As shown in FIG. 2, the graph-based document DOM structure consists ofnodes and leaves. The nodes serve as the parents of leaves and nodes,while leaves are end points of a branch in the graph. Each node and leafcan have a set of attributes to specify its own characteristics. Forexample, a paragraph node can contain attributes to specify itsalignment, style, entry of document TOC, etc. In addition, each of thenodes and the leaves has a unique identifier, called a DOM ID, toidentify itself in the document DOM structure.

The document DOM structure is divided into three parts: top-level,component and references. The top level refers to the document rootstructure, while the main document is constructed in the component andthe references represent document references to either internal orexternal subdocument parts. The following paragraphs examine each partin detail.

The root node of a document DOM structure, referred to as “Document”,contains several children nodes, referred to as “Contents”, whichrepresent different aspects of the document contents. Each “Contents”node contains one or multiple “Container” nodes used to store variousdocument global attributes. The children of the “Container” nodes arecomponents, which store the document structural and navigationalinformation. When the attachment server 28 builds the DOM structure foran attachment file for the first time, the top-level structure is asingle parent-child chain as shown in FIG. 3:

Three types of components are defined by the attachment server 28: textcomponents, table components and image components, which represent text,tables and images in a document, respectively. The text and tablecomponents are described in detail below, and the image componentstructure is identical.

A component consists of a hierarchy of command nodes. Each commandrepresents a physical entity, a property, or a reference defined in adocument. For the text component, the physical entity commands are page,section, paragraph, text segments comments, footnote and endnotecommands, which by name define the corresponding entity contained in adocument. The property commands for the text component are font, textcolor, text background color, hyperlink start/end and bookmark commands.The text component has only one reference command, referred to as thetext reference command, which is used to reference a subdocument definedin the main body of a document. Usually, the children of a textcomponent are page or section command nodes that, in turn, comprise aset of paragraph command nodes. The paragraph command can contain one ormultiple nodes for the remaining command types.

Using the following sample text document, the corresponding document DOMstructure is shown in FIG. 4: First paragraph. Second paragraph withbold and red text.

As FIG. 4 demonstrates, the section command, which is the child of thetext component, consists of two paragraph commands. The first paragraphcommand contains one text segment command and the text content for thatparagraph is added as an attribute to the text segment command. Thesecond paragraph command has a relatively more complex structure, as thetext properties in the paragraph are much richer. Each time a textproperty (font, text color, etc) changes, a corresponding text propertycommand is created and the change value is added to that command as anattribute. The subsequent text segment command records the text with thesame text property as an attribute. As document structure gets richerand more complex, more commands of corresponding types are created andthe document properties are added as attributes to those commands

The table component has the same three types of commands as the textcomponent, but different command names. The document DOM structure forthe sample table document below is shown in FIG. 5: Cell One Cell TwoCell Three Cell Four

As shown in the FIG. 5, the table component has physical entity typecommands of table, tablerow and tablecell, where the tablecell commandcan contain all available commands for the text component. In theexample above, the first child TableRow command of the table command hasan attribute “Index” defined by value of 0. This indicates that theindicated table row is the first one defined in the table The attributeof the leftmost table cell command in FIG. 5 has the same meaning.

A document sometimes contains subdocuments, for example images, tables,text boxes etc. The DOM structure set forth herein uses a referencecommand to point to the graph of such subdocuments. Thus, for thefollowing sample document, the attachment server 28 generates the DOMstructure shown in FIG. 6:

The structure shown in FIG. 6 is identical to that discussed above inconnection with FIGS. 4 and 5, except for the attributes of the tworeference commands. The attachment server 28 constructs the image in“Sample Three” as a separate image component, which contains all of theimage data in its own DOM hierarchy. In the DOM structure for the maindocument, the values of the “Ref” attributes of those two referencecommands point to the image component, as indicated by the dashed lines,such that the DOM structure connects together all parts of the document.

Having described the document DOM structure used to implement anembodiment of the invention, a detailed discussion will now be providedof the document information construction, delivery and display functionor method according to the preferred embodiment.

With reference to FIG. 7, after receiving an email with renamedattachments on a mobile device 12 (step 30), the user can send a requestto the server 28 for the associated document information. Once theserver receives such a request, it initially constructs only the toplevel of the document DOM structure for the attachment (step 32), asdiscussed above in connection with FIG. 3. Construction of the top levelof the document DOM structure is a very fast operation, therebyminimizing wait time for the user. The server 28 then examines thedocument binary data (step 34) to find the basic document information(i.e. type, author, creation time and date, modified time and date,format type, etc) for the document.

Specifically, the file is opened in binary mode and searched to locate afile signature. The signature of the file is stored either at thebeginning or at the end of a file (usually the first or last tens to afew hundred of bytes), and is used to indicate identify the file type(i.e. document original format type, discussed in greater below). Forexample, the signature of the PDF document original format type, “%PDF”, is contained in the first 4 bytes of the raw binary data of a PDFfile. For other types of information, the binary file must be searchedfurther.

Or, since MS Office® files are “storage” type files (rather than“stream” type files such as PDF and text file), which can containsub-streams and sub-storage, the first 8 bytes need to be a fixed value.Therefore, after confirming that the file is “storage” type, the server28 searches for a stream called “WordDocument” contained in the file toverify that a file is a MS Word® file.

Directly examining binary data ensures that any macro or operation inthe attachment is not executed, thereby eliminating any chance of virusattacks and/or other security threats.

After retrieving all of the available document information stored in thefile, the server 28 adds the retrieved information as attributes to theroot component of the DOM structure (step 36).

It will be appreciated that, compared to retrieval of the entiredocument contents, the document information search and constructionprocess of FIG. 7 is much simpler and quicker, especially for largedocuments, since the server 28 usually does not have to parse deep intothe file to locate the document information. After the documentinformation is constructed, the server 28 sends a response back to theclient device 12 (step 38) over a standard transportation channel.

After the client device 12 receives the requested document informationfor an email attachment, it displays the information to the useraccording to type. Specifically, server 28 indicates the documentoriginal format type in five categories: Archives, Documents,Spreadsheets, Presentations and Images. These five categories are eachrepresented by a unique icon displayed on the screen of the mobiledevice 12 which, according to the preferred embodiment, are as follows:Icon Attachment Type Supported Sub document types

Archives ZIP Archives. Only used in Attachment List Screen

Documents MS Word, Adobe PDF, Corel WordPerfect, ASCII Text, HTML

Spreadsheets MS Excel

Presentations MS PowerPoint

Images BMP, PNG, GIF, TIFF, JPEG

The server 28 also preferably sends the document format subtype to themobile device 12. For example, MS Word® and Adobe® PDF are bothcategorized as type “documents”, which is further specified by theserver 28 using the different subtypes, as indicated above. In additionto the document type, other document information, such as size, creationtime, last modified time and author are also sent to the client device12.

The client device 12 displays the information in a static or dynamicfashion. With static display, the client device 12 displays theinformation on a static area, (e.g. title bar, etc.) of the devicescreen. With dynamic display, the client device 12 first caches thedocument information and then displays it using dynamic GUI elements,(e.g. pop-up message box, etc.) in response to a query from the user.

FIG. 8A shows a static display of document type whereas FIG. 8B showsboth the static display of document type and a pop-up message box fordynamic representation of the remaining document information sent fromthe server 28.

In summary, the method of document information delivery and displayaccording to the preferred embodiment allows a mobile device user toquickly determine if an attachment is of interest without having toretrieve the document content itself, thereby minimizing overall networkbandwidth.

A person skilled in the art, having read this description of thepreferred embodiment, may conceive of variations and alternativeembodiments. All such variations and alternative embodiments arebelieved to be within the ambit of the claims appended hereto.

1. A process for viewing document information on a mobile communicationdevice relating to a document stored on a server, without downloadingsaid document from the server to the mobile device, comprising:transmitting a request for said document information from said mobiledevice to said server; constructing a top level graph structure withinsaid server representing a map of said document, said top level graphstructure including a root node and at least one child node; examiningsaid document within said server for said document information;retrieving and adding said document information within said server as anattribute to said root node of said top level graph structure; sending aresponse from said server to said mobile device containing said documentinformation; and receiving and displaying said document information onsaid mobile device.
 2. The process of claim 1, wherein said examiningsaid document for said document information comprises searching documentbinary data of said document to find said document information.
 3. Theprocess of claim 1, wherein said top level graph structure is a DocumentObject Model (DOM).
 4. The process of claim 3, wherein said DocumentObject Model (DOM) comprises said root node, and at least one contentsnode depending from said root node, at least one container nodedepending from said contents node, and at least one component nodedepending from said container node.
 5. The process of claim 4, whereinsaid at least one container node stores document global attributes andsaid at least one component node stores document structural andnavigational information.
 6. The process of claim 1, wherein saiddisplaying further comprises presenting said document information on astatic screen area of said mobile device.
 7. The process of claim 6,wherein said static screen area is a title bar.
 8. The process of claim1, wherein said displaying further comprises caching and then presentingsaid document information using GUI elements on a dynamic screen area ofsaid mobile device.
 9. The process of claim 8, wherein said GUI elementsinclude a pop-up message box.
 10. The process according to claim 1,wherein said document information includes document original format typeand subtype.
 11. The process of claim 10, wherein said document originalformat type includes any one or more of Archives, Documents,Spreadsheets, Presentations and Images.
 12. The process of claim 11,wherein said Archives, Documents, Spreadsheets, Presentations and Imagesare represented on said mobile device by respective icons.
 13. Theprocess of claim 10, wherein said subtype identifies a unique softwareapplication.
 14. The process according to claim 10, wherein saiddocument information includes additional information including at leastone of size, creation time, last modified time and author.
 15. A serverprocess comprising: constructing a top level graph structure within saidserver representing a map of a document, said top level graph structureincluding a root node and at least one child node; examining saiddocument for document information; retrieving and adding said documentinformation as an attribute to said root node of said top level graphstructure; and transmitting said document information.
 16. The serverprocess of claim 15, wherein said examining further comprises searchingdocument binary data of said document to find said document information.17. The server process of claim 15, wherein said graph structure is aDocument Object Model (DOM).
 18. The server process of claim 17, whereinsaid Document Object Model (DOM) comprises said root node, and at leastone contents node depending from said root node, at least one containernode depending from said contents node, and at least one component nodedepending from said container node.
 19. The server process according toclaim 15, wherein said document information includes document originalformat type and subtype.
 20. The server process of claim 19, whereinsaid document original format type includes any one or more of Archives,Documents, Spreadsheets, Presentations and Images.
 21. The serverprocess of claim 19, wherein said subtype identifies a unique softwareapplication.
 22. The server process according to claim 19, wherein saiddocument information includes additional information including at leastone of size, creation time, last modified time and author.
 23. A mobiledevice process comprising: transmitting a request for documentinformation; and receiving and displaying said document information onone of either a static display area or a dynamic display area of saidmobile device.
 24. The mobile device process of claim 23, wherein saidstatic screen area is a title bar.
 25. The mobile device process ofclaim 23, wherein displaying said document information on dynamicdisplay area further comprises caching and then presenting said documentinformation using GUI elements on a dynamic screen area of said mobiledevice.
 26. The mobile device process of claim 25, wherein said GUIelements include a popup message box.
 27. The mobile process accordingto claim 23, wherein said document information includes documentoriginal format type and subtype.
 28. The mobile process according toclaim 27, wherein said document original format type includes any one ormore of Archives, Documents, Spreadsheets, Presentations and Images. 29.The mobile process according to claim 28, wherein said Archives,Documents, Spreadsheets, Presentations and Images are represented onsaid mobile device by respective icons.
 30. The mobile process accordingto claim 27, wherein said subtype identifies a unique softwareapplication.
 31. The mobile process according to claim 27, wherein saiddocument information further comprises other document informationincluding at least one of size, creation time, last modified time andauthor.